新装版 達人プログラマー 職人から名匠への道
https://images-na.ssl-images-amazon.com/images/I/51aDNpMj8hL._SX350_BO1,204,203,200_.jpg
購入 : 2020-09-13
読了 : 2020-09-18
感想
心構えとか考え方が述べられているのが良い
結構幅広い
良かったところとか気になったところのメモ
まえがき
大規模なプロジェクトでは個人の力が入り込む余地はないと感じる人がいるかもしれない
それには賛成できない。 プロジェクトは技術的戒律に従うべきものだが、それでも個性と技芸に対する心意気の入り込む余地はある
継続は力。 素晴らしい芝生を育てるには毎日の世話が大事なように、偉大なプログラマーになるにも日々の継続が必要
経営コンサルタントがよくいう 「カイゼン」。 数多くの小さな進歩を継続して行うという概念 1 章 : 達人の哲学 A Pragmatic Philosophy
達人プログラマーは自分自身の経歴を管理し、無知や誤りを認めることを恐れない
自分の能力に誇りを持つことはよいことだが、無知は誤りであると考え、自分の欠点に正直になること
結果に対する責任を負うということは、実際に責任を取ることが求められる。 過ちや判断ミスをしたときには、それを認めて対応策を考えて提案を試みる
そうだね nobuoka.icon
「割れた窓」 (悪い設計、間違った意思決定、質の悪いコード) を放置してはならない 触媒として作用する : 好奇心を刺激して巻き込んだり、複数人を団結させて一人では成し遂げられないことを達成する
「疲労の開始」 と呼ばれる現象 : 取り組みの承認を得る前に足止めを食らうことがある。 みんな自分のリソースを守ろうとする 道理にかなった要求を考えて、それを引き出せるようにそれなりの物を作って人に見せて驚かせる。 そこからおもむろに 「～～ を追加するともっとうまくいくんだけどなぁ」 と重要でないことのように言う
巻き込まれる側の立場でいうと、ゆでガエルのように変化を感じられないうちに茹でられるのではなく、しっかりと変化を感じるように
開発するシステムの適用範囲と品質はシステム要求の一部として仕様化されなければならない
どこまでやるのか？ 今日の素敵なソフトウェアは明日の完璧なそれよりも好まれる
知識と経験は最高の資産。 だが、技術の進歩の速さによりその陳腐化は速い
自身の知識ポートフォリオを形成せよ
読書の習慣をつけ、毎月 1 冊読書しましょう
アイデアの相互交流は大事 (直接業務に関わるものではなくても、学習の過程で思考に幅ができる)
一日の大半を伝達に費やす (コーディングもコンピュータに実行させる作業を伝達するためのコード) わけなので、それを円滑に進める必要がある
草稿段階から読者を巻き込んでいく。 早めのフィードバックを得る
チーム内での伝達についての良書
2 章 : 達人のアプローチ
保守 (メンテナンス) のことをバグの修正と機能拡張で、リリース後に行うものだと思っている人がいるが、それは違う
プログラマは常に保守モード。 我々の理解は日々変わるし、設計やコーディングをしていても新たな要求が出てくる
保守は全ての開発工程を通じて行う日常業務
開発そのものを理解しやすく、維持しやすくするために、DRY 原則が重要 コードだけでなくあらゆる知識の二重化を避けること
コードジェネレータを使うとか、仕様からテストを作るとか、そういうのも含めて
達人プログラマーの道具の中で最も重要なもののうちの一つ
本書のトピックの多くは柔軟で適合性のあるソフトウェアを生み出すためのもの
後戻りを許されない多くの重大な決定から解放される → 可逆性
曳光弾 : フィードバックが即座に得られる。 通常の弾と同じ環境で使用されるために外部からの影響が最小限 ソフトウェア開発でも同様に、目標とのずれを把握するために動くものを早く作るという手段を取れる
曳光弾の概念も初めて知った nobuoka.icon
プロトタイピングとは異なる。 プロトタイピングはシステムの最終形態に対する理解を検証するためのもので、コンセプトの確認を終えたら捨て去られる 曳光弾のコードは最小限ではあるが完全なものであり、継続して使用される
プロトタイプ : リスクを分析し、変更を安価に行うために作成 プロトタイプの重要な点は経験学習にある。 プロトタイプ自体に価値があるのではなく、そこから学んだ教訓に価値がある
見積もり
全ての見積もりは問題をモデル化するところから
プロジェクトであれば、開発に用いられるフェーズやシステムの実装方法の概要をモデル化
モデル化ができたらコンポーネントに分解する。 コンポーネントの相互作用を説明する規則が必要になることも
何を訊かれているのかを理解するところから。 問題領域を把握すること
同様の経験をした人から聞くのが精度を高める秘訣
見積もりに失敗したならば、なぜ違ったのか見つけ出すこと
3 章 : 基本的なツール
技術の世界は日進月歩なので、この章に書かれているツールは既に古くなっている可能性がある
たとえそうだとしても、テキストデータの潜在能力やシェルの便利さなどの、抽象的な部分での理解は意味がある
デバッグについて
バグという言葉は 14 世紀から 「恐ろしいもの」 を表すために用いられていた
そうなのか nobuoka.icon
デバッグの戦略
バグ修正にあたって最初にやるべきことはバグを再現させること
バグが長い手順に従わないと再現しないような状況ではデバッグしづらい
単純なコマンド 1 つで再現できるようにする
開発中に発生するバグはほとんどがアプリケーションに原因をもつ
サードパーティライブラリに原因があることはほとんどない
ライブラリ等に問題があるように見えても、使い方がおかしいとかがほとんどなので、最初から外部に原因を求めない方がよい
仮定せずに証明すること : 驚くような現象が起こっても起こっていることは事実
コードジェネレータ
2 種類ある
消極的なコードジェネレータ : 成果物を造り出すために一度だけ実行される。 それ以降の結果は独り歩き
利便性の追求
積極的なコードジェネレータ : 結果が必要となるたびに使用するもの
DRY 原則のために必要
4 章 : 妄想の達人